Quality Time - Can Chaotic Methods Improve Software Quality Predictions?

P redictability is a measure of how accurately we can forecast a future event. 100% predictability is synonymous with omnipotence, 0% with having no clue whatsoever. Analog devices generally provide good levels of predictability. For example, manufacturers sell light bulbs with MTTF (mean time to failure) scores. A car traveling at 40 mph will still be traveling at a speed plus or minus some small amount from 40 mph a second later, assuming no obstacles exist. Even analog systems such as the weather are quite predictable if we only look at the immediate future. Software system predictability, however, is quite different from that of analog systems and devices. When we say a software package is high-quality, we mean that it will behave in a manner we've defined as acceptable. That is, we generally expect it to be available, operate as it's supposed to, and rarely fail. Unfortunately, the key word here— " generally " —is not a strong enough assertion for systems that can't tolerate failure. General statements about quality don't provide confidence about how software will behave, no matter how immediately into the future we predict. Flip one bit one nanosec-ond later, and all bets are off on what the consequences will be. Two interacting culprits cause our inability to precisely (as opposed to generally) predict a software program's behavior: hidden defects (faults) and enormous input spaces. If the input-space size were more tractable and we could identify all existing faults, the predictability problem would decrease substantially. To have 100% software quality predictability , we must know each fault's consequences. This requires the impossible task of knowing each fault's location and how each fault interacts with each software input. Because 100% predictability is impossible , the question becomes, " How close to it can we come and how? " Faults First, look at the problem caused by incorrectly coded logic. Faults are manifestations of mental mistakes (usually called errors) by programmers and system designers. If we knew where all the faults were in a program, we could reduce unpredictability by fixing them or determining their behav-ioral consequences. Fixing them would be preferable if we could fix all faults without new ones arising. But let's look at the magnitude of the problem of doing so. For simplicity, let's assume only one defect exists in a program comprising one million source lines of code. And assume we know the defect is …